The operation of applications, such as database (DB) applications for example, may involve multiple different device types. Thus, in the example case of a DB application, data devices, log devices, index devices, and other devices, may be employed in connection with the operation of the application. In order to prevent against data loss, natural disasters, and other problems, many enterprises choose to replicate, or otherwise protect, the application and associated devices. Replicating or otherwise protecting the application, data generated by the application, and associated devices, such as by way of remote relocation or snapshots for example, typically requires that the data devices, but not the logs or index devices, be replicated/sent-remotely.
Typically, the user is required to specify which devices to replicate, and also to specify which devices do not require replication. In some cases, the user can do this by placing the devices in different respective storage groups (SG), that is, devices to be replicated are placed in one storage group, while devices that will not be replicated are put in a different storage group. To illustrate, a user may decide that a data device SG will be replicated but a log/index SG will not. One consequence of this approach is that a single application will have, or be associated with, multiple different SGs. Since the application devices are spread out over multiple SGs, management of the application devices may be complex and difficult.
The user can avoid the multiple SG problem by placing all of the devices in a single SG. However, this approach presents problems of its own. For example, because all the devices are in a single SG, the user must specify, on a per-device basis, how each device will be handled. This is typically performed manually, that is, the user must manually mark the devices that are to be excluded from replication. Because SGs can be quite large, a single SG may include as many as 50K-60K devices, this manual approach is not practical in many cases.